Prior art diagnostics software allows users to execute test scripts (also called “tests”) on application software of the type included in, for example, an Enterprise Resource Planning (ERP) suite. The prior art diagnostics software may provide a framework to integrate test cases and automate the execution of test cases. The framework may provide mechanisms to write (and run) tests, either in Java or in a procedural language used in database management systems (DBMS) such as PL/SQL supported by software available from ORACLE Corporation. Other examples of a DBMS procedural language include SQL/OLB (which forms part 10 of the ANSI SQL-99 standard, and defines extensions of SQL to support embedding of SQL statements into programs written in Java), MICROSOFT's Transact-SQL language, and IBM's Persistent SQL Modules (PSM) language. Vendor-specific SQL procedural languages are incompatible with one another and this could be a reason why users (also called “test developers”) may choose to write test scripts for more than one vendor's systems, using Java.
Test scripts can be written through a tool for writing Java software such as JDeveloper available from Oracle Corporation and/or any editing tool for writing PL/SQL software, such as Notepad available from Microsoft Corporation, or a diagnostics application's user interface or via a Web-based user interface (UI). Metadata about test scripts may be stored in diagnostic schema. One such prior art system is illustrated in FIG. 1A, which is described briefly below and in greater detail in U.S. patent application Ser. No. 10/991,607 filed on Nov. 17, 2004, with Sowmya Subramanian as the first inventor that is incorporated by reference herein in its entirety. See also U.S. patent application Ser. Nos. 10/991,608, and 10/991,883 that are both also incorporated by reference herein in their entirety as background.
FIG. 1A is a diagrammatic representation of an implementation architecture of a diagnostics and testing framework of the prior art. An architecture 100, which may be part of a computing system (FIG. 1B) which includes processors and storage devices on which code devices associated with the architecture are stored, is arranged to provide a diagnostics and testing framework, e.g., a testing framework. Within architecture 100, repositories 101 and 102 are arranged to store data, e.g., repository 102 is arranged to store information pertaining to one or more tests. Repository 101 may be a database that stores tables of data. When an execution engine 103 runs a test 109 via a method of a predetermined name (e.g. “runtest” method 104 in FIG. 1A), execution engine 103 accesses the information in repositories 101 and 102. Execution engine 103 also logs information via a writer (not labeled with a reference number in FIG. 1A).
In general, execution engine 103 (FIG. 1A) includes core execution logic associated with architecture 100, and delegates calls or logic to appropriate sources. Execution engine 103 may take user commands and cause a test script to be run and registered, and also cause test results or output to be displayed as appropriate. For example, when a test script is to be run, execution engine 103 calls into a test interface 105 which effectively provides handshaking between execution engine 103 and adapters such as PL/SQL adapter 107 and SQL test adapter 108, and Java tests 106.
Java tests 106 which contain runtime information, a PL/SQL adapter 107, and SQL test adapter 108, and any other such adapters are all arranged to interface with execution engine 103 via test interface 105. Such elements effectively rewrite data into a language or format that is understood by test interface 105. Each of the elements which are effectively plugged into test interface 105 include a generic adapter portion or a common layer. Each element plugged into test interface 105 essentially extends the functionality or logic associated with the generic adapter portion. Note that a runtime data store is part of execution engine 103 in FIG. 1A, and the store is accessed via a Java data structure that was used for pipelining (i.e. transfer) of data only between two tests that were both written in Java.
For use in such an architecture 100 (FIG. 1B), a test script can be written by a user (or test developer) 130 for use as an individual test, or as a container test (also called “master” test) that causes execution of multiple individual tests (also called “dependencies”). In FIG. 1B, testA (labeled with reference numeral 111) and testB (labeled with reference numeral 112) are individual tests which are intended to respectively test Application A (labeled with reference numeral 121) and Application B (labeled with reference numeral 122). An example of Application A is ORACLE Inventory Optimization. An example of Application B is ORACLE Order Management. The user 130 also writes a container test (labeled with reference numeral 113) which contains the names of these two test scripts 111 and 112, and these two tests are executed when the container test is executed. Note, that container test 113 contains test names but does not contain (or replicate) commands that are present in individual test scripts 111 and 112.
Individual test scripts that are manually written in Java (such as testA and testB) for use in ORACLE Diagnostics, version 2.2 or 2.3 can be “pipelined” to pass data therebetween. Examples of test scripts 111 and 112 are illustrated in FIGS. 1C and 1D. Pipelining enables passage of output parameters from one individual Java test (such as testA test script 111) which data may be temporarily held in a run time data store (labeled with reference numeral 123 in FIG. 1B) as input parameters of a next individual Java test (such as testB test script 112), if both tests are named within a container test (such as container test 113).
An example of lines written by a user 130 as container test 113 is illustrated in FIG. 1E. As noted above, a container test (such as test 113) does not contain the actual software present in the individual test scripts (such as tests 111 and 112) to be pipelined, and instead the container test script contains the names of the individual test scripts. To support pipelining of data between individual test scripts as shown in FIG. 1E, a user 130 must add lines of the type illustrated in FIGS. 1C and 1D to the individual test scripts 111 and 112. For example, user 130 must write the first Java test script to specify the output values to be passed from itself (see FIG. 1C) to the next Java test script (see FIG. 1D). This is illustrated in FIG. 1C, by using a hash table to return a result 140 from the getOutputValues( ) API, which is a function 141 that user 130 manually writes for each individual Java test script, if it is to be a member of a pipeline in a container test.
Note that output data in result 140 of FIG. 1C (which is stored in runtime data store 123 in FIG. 1B) is not passed from a current Java test script to the next Java test script unless that next Java test script specifies input parameters of precisely the same name as the output parameters of the current Java test script. This is illustrated in FIG. 1D, by use of the Java function getInputValue( ) API, in statements 142 and 143 which reads from the runtime data store the values of parameters “Username” and “LanguageCode” respectively.
Moreover, the user 130 must also initialize, in container test 113 (see FIG. 1E), an array of strings called “dependentClassNames” (labeled with reference numeral 144 in FIG. 1E) to the individual names of test scripts that are being pipelined. Note that the names of the two tests shown in FIGS. 1C and 1D are stored in the “dependencies” variable in statement 147 (FIG. 1E). Additionally user 130 must set a flag called “isDependencyPipelined” (labeled with reference numeral 145 in FIG. 1E) to the value “true”.
In response to container test 113 (FIG. 1E), a prior art execution engine 103 (FIG. 1A) performs the method 150 illustrated in FIG. 1F. Specifically, after receipt of the tests in step 151, engine 103 creates an array containing the test names (as per step 152), followed by use of the array to initialize a Java object for each test name (as per step 153). In step 154, a loop variable I is initialized to 0, followed by steps 155-159 as discussed next.
In act 155 (FIG. 1F), engine 103 checks to see if a current Java object corresponding to the current test name identified by array element I requires any input and if so goes to step 156 and alternatively goes to step 158. In step 156, engine 103 checks if the current object already has input, and if not an error is reported and if so, goes to step 157 wherein data from a runtime data store 123 is set up as the input data. Next in step 158, engine 103 calls the run test method of object I, followed by execution of the test, followed by storing the output in runtime data store 123 (FIG. 1B). Note that runtime data store 123 of the prior art is used only to store the data output by tests which are expressed in Java.
Next, engine 103 goes to step 159 wherein the loop count I is incremented and if not all tests specified in container test 113 have been performed, returns to step 155. When pipelining data between individual tests as shown in steps 155-159, an execution engine of the prior art does not execute any database queries, and instead simply executes the byte codes of Java which are present in each of tests 111-113.
Note that in the prior art Java test script (shown in FIG. 1D), a user could specify a value for input parameters in a constructor (e.g. via the function “addInput( . . . )”), e.g. if this value would not be passed to it by the previous Java test script (i.e. if script 111 shown in FIG. 1C was not used). It was common for an addInput function to be used in the prior art (see statements 146 in FIG. 1D) to specify input parameters that a test was to have, with certain prompt names (e.g. “Username” and “LanguageCode” in statements 146) in a user interface (UI) web page, and corresponding default values (e.g. “SYSADMIN” and “US” in statements 146) to which these input parameters were to be initialized.
Hence, input values if specified by a test (via addInput) or if corresponding values are received from a database or a user, then such values (“original values”) were automatically passed to each individual Java test specified as a dependency in a container test, whether the Java test was pipelined or not pipelined. However, if an individual Java test was pipelined, then it's output values when saved in the runtime data store overwrite any pre-existing values in the runtime data store thereby passing the output values to a next Java test.
To the knowledge of the inventor of this current patent application, to pipeline Java tests in prior art system 100 (FIG. 1A), a test developer needs to: (1) write a container test in Java, which contains test names to be pipelined as the value(s) for a predetermined class “dependentClassNames,” (labeled with reference numeral 144 in FIG. 1E) (2) return value of “isDependencyPipelined” set to “true” (labeled with reference numeral 145); and (3) for the test to be pipelined, write a method getOutputValues( ) to retrieve the output data from the first test in the form of a hash table and to supply this data as the input data of the second test (labeled with reference numeral 141 in FIG. 1C).
To the knowledge of the inventor of this current patent application, the above-described prior art system 100 did not support pipelining between PL/SQL tests, although individual PL/SQL tests could be executed via PL/SQL adapter 107 (FIG. 1A). FIGS. 1G and 1H illustrate a PL/SQL test called “testC”. In the prior art, in act 155 (FIG. 1F) if a test 109 (FIG. 1A) was written in PL/SQL, the execution engine used database connectivity to open a database call and execute a procedure “getDefaultTestParams” to check if the test had any input parameters. Also, in the prior art method, in act 156, the execution engine checked if data for a PL/SQL test was available via a user interface or via default input but did not check the runtime store accessible to Java objects because the test was written in PL/SQL.
After execution of the “runtest” procedure of a testC (labeled with reference numeral 161 in FIG. 1H) in act 158, the execution engine 103 receives PL/SQL variables “report” and “reportClob” (labeled with reference numerals 163 and 164 in FIG. 1H). However, there was no mechanism in execution engine 103, prior to the invention described below, for testC (written in PL/SQL) to write into or in any manner retrieve data from a runtime data store used by Java objects. Moreover, there was also no mechanism prior to the invention for testC (written in PL/SQL) to communicate any information to/from another PL/SQL test.
Accordingly, if pipelining of data was necessary between two tests in prior art system 100, e.g. in order to test interaction between two applications sold by Oracle Corporation, as data pipelining was not supported for PL/SQL tests, the user (or test developer) 130 could write both test scripts in Java, but this requires the user to be knowledgeable about Java. Hence, the current inventor believes there is a need to enable pipelining of data to or from a PL/SQL test script, which need can be met as discussed below.